A tendency that has been observed for many years in the manufacture of not only automobiles, but also in other sectors in the design and manufacture of vehicles of any type, and in all other mechanical engineering and plant construction sectors, is that the products contain more and more electronics. The contribution of electronics to automotive value creation is already about 35 percent, with an upward tendency. A large portion of this contribution to value creation is related to control units which monitor the various devices of the overall products. These traditional control units are generally permanently programmed, and cannot be modified at all, or only to a very limited extent, at a later time.
However, in order to adapt the control units to their respective environments, it is necessary to be able to make modifications to the control unit in order to determine the optimum operating parameters for a particular application. Such modifications relate mainly to changes to boundary conditions, i.e., to changes to the data stored in the memories of the control unit.
In order to be able to carry out suitable tests on the respective control units, one can use influencing devices, which allow the desired modifications to be made to the control unit.
Influencing devices are known in the field and are used primarily in applied research and industrial development where the aim is to develop control units and bring them into use. An example of an influencing device is described in International Patent Application WO 2005/091089 A1.
In the following, the term “control unit” will be understood to include all types of electronic devices used for influencing technical-physical processes. Such a control unit usually includes at least one processing unit, for example in the form of a microprocessor or microcontroller. The control unit also includes a memory and input/output (I/O) interfaces to be able to perform calculations as a function of internally stored parameters or internal operands and/or measured (or at least externally provided) variables and, at the same time, to be able to influence external processes by outputting electrical signals. Thus, from a control engineering point of view, control units do not just operate as open-loop controllers. Rather, they are, in particular, also capable of performing complex closed-loop control tasks. Whenever the description below refers to control units, controllers, and the process of controlling, it is understood that these terms also include devices and processes according to the more general definition given above.
Moreover, the following description frequently refers to various microcontrollers, which will be understood to mean electronic processing units having electronic memory associated therewith, irrespectively of whether the memory is partially or completely implemented together with the processing unit in a single part, or whether the processing unit and the associated memory are separate parts.
The use of influencing devices is illustrated in the following description of the development process that control units go through in practice, at least with respect to complex tasks.
Any control engineering task begins with the mathematical modeling and simulation of a technical-physical process upon which a desired dynamic behavior is to be imposed. Based on the resulting abstract mathematical model, it is possible to test different control concepts, again available exclusively as a mathematical model concept, within the framework of numerical simulations. This stage is the phase of modeling and controller design, based mostly on computer-aided modeling tools.
In a second step, the controller designed in the mathematical model is transferred to a real-time capable simulation unit, which usually has a much better performance than a conventional standard control unit in terms of both computing power and I/O capabilities, and which is in an interactive communication with the real physical process. Since the transfer of the abstractly-formulated controller from a modeling tool to the simulation unit occurs substantially automatically, the second phase is also referred to as rapid control prototyping (RCP) or function prototyping.
Once the control engineering task is achieved by the controller operating in the simulation unit, the control algorithm is transferred, during controller implementation, to the standard control unit to be ultimately used in practice, usually in a fully automatic manner.
Frequently, the control unit, which in principle can now be used in a real process, is initially subjected to a test before it is used in practice. In such a test, the real process, with which the control unit is ultimately intended to interact with, is partially or completely simulated by a real-time capable simulation unit, and the control unit is simulated by a signal test pattern (e.g., hardware-in-the-loop simulation). The control unit tested in this manner is ultimately used in the real process and operated interactively therewith.
In spite of the previously performed comprehensive testing, it is usually necessary to make adjustments to the control unit, or to the functions implemented in the control unit. For this purpose, first of all, the state of the control unit, i.e., all data that is read or output or internally used by the control unit, must be capable of being promptly monitored, recorded, and analyzed through data acquisition. Secondly, the parameters or sets of parameters, i.e., the characteristic values, curves, and maps, on which the functions/control algorithms are based, must be capable of being changed through writing access to the memory of the control unit. The above-described processes are altogether referred to as control unit applications.
In cases where not only parameters of the functions of the control unit, i.e., data stored in the memory of the control unit, but also the actual functions implemented in the control unit are to be changed for testing purposes, the so-called “function bypassing” is used. During function bypassing, the control unit signals to a real-time capable simulation unit that a control unit function has been called, but does not itself perform the function. Instead, the control unit receives and uses the result calculated in the simulation unit for purposes of substitution. Thus, the control unit function is bypassed.
In both the control unit application and function bypassing scenarios described above, it is necessary to provide a special access to the control unit, via which the control unit can be monitored and actively influenced. This is the task of influencing devices.
In practice, various methods are known for accessing control units via influencing devices. These methods include access via a parallel interface, access via a serial interface, or access via a special debug interface, frequently in addition to other serial and/or parallel interfaces. The debug interface itself may be in the form of a serial or parallel interface, or be a combination of these two types.
Depending on the design of the control unit, it may be necessary to interfere with the hardware of the control unit when using a parallel interface, because frequently the influencing device operates as a memory emulator.
It is known that a memory, or selected memory areas of the memory, of a memory emulator may take the place of a memory device or memory area of the control unit, or be accommodated in a slot especially provided for this purpose on the circuit board of the control unit. After the memory emulator is connected to the control unit, a control unit microcontroller accesses the memory contents of the memory emulator via the address and data buses.
Modern control units are increasingly equipped with microcontrollers having a debug interface, such as NEXUS (IEEE-ISTO 5001: “The NEXUS 5001 Forum Standard for a Global Embedded Processor Debug Interface”, 2003).
Debug interfaces offer far-reaching possibilities for monitoring and influencing microcontroller states and allow for run-time monitoring and control (e.g., debugging) of the microcontroller, making it possible, in particular, to trace the execution of program code and the data accessed and modified in the process. Because debug interfaces form an integral part of the microcontroller hardware, they allow the microcontroller to be accessed much faster than is possible when using a software-based communications interface.
Thus, using a suitable interface instruction set, the debug interface of a control unit makes it possible to automatically read out and actively influence the state of a control unit microcontroller, and, to some extent, also the states of units associated therewith in the control unit (e.g., the state of its external memory).
The term “control unit debug interface” as used herein will be understood to also include interfaces which are not primarily intended as “debug interfaces” and therefore are not explicitly referred to as such, but which offer such monitoring and influencing capabilities with respect to the control unit microcontroller and the electronic units associated therewith.
International Patent Publication WO 2005/091089 A1 describes the use of the control unit debug interface for data exchange between the influencing device and the control unit to be influenced.
It is also known that the application of a control unit having a control unit debug interface can be done using an influencing device (see, dSPACE catalog 2006, pp. 430-432, influencing device DCI-GSI1) which uses the control unit debug interface (for example, the Nexus interface) for influencing the control unit. Until now, the exchange of data (e.g., protocol information, variables, constants, instructions, functions, programs, etc.) between the control unit and the influencing device could only be carried out via such debug interfaces when the control unit was ON.
In traditional systems, the influencing device and control unit are directly coupled via a debug interface. However, in an arrangement where the influencing device and the control unit are directly coupled via a debug interface, data exchange cannot even start when the control unit is OFF.
One of the reasons for this is that certain protocol information must be exchanged before payload data can be exchanged between the debug interface of the influencing device and the debug interface of the control unit. In the special case where a control unit microcontroller located in the control unit can be turned off independently of the control unit, the operational readiness of the debug interface of the control unit is usually still linked to the operational readiness of the control unit microcontroller.